Skip to content

Support PEP420 (implicit namespace packages) as --pyargs target. #13426

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

karlicoss
Copy link

Previously, when running --pyargs pkg, if you didn't have pkg/__init__.py, pytest would fail with ERROR: module or package not found: pkg (missing __init__.py?).

Now it's discovering the package and tests inside it correctly.

If used in conjunction with consider_namespace_packages in config, test modules get correct __package__ and __name__ attributes as well.

Fixes: #478

Other relevant issues:

In addition, remove "namespace" origin handling -- this value isn't used since python 3.8. See:

Previously, when running `--pyargs pkg`, if you didn't have `pkg/__init__.py`,
pytest would fail with `ERROR: module or package not found: pkg (missing __init__.py?)`.

Now it's discovering the package and tests inside it correctly.

If used in conjunction with `consider_namespace_packages` in config, test
modules get correct `__package__` and `__name__` attributes as well.

Fixes: pytest-dev#478

Other relevant issues:
- pytest-dev#2371
- pytest-dev#10569

In addition, remove `"namespace"` origin handling -- this value isn't used since python 3.8.
See:
- python/cpython#5481
- https://docs.python.org/3/library/importlib.html#importlib.machinery.ModuleSpec.submodule_search_locations
@psf-chronographer psf-chronographer bot added the bot:chronographer:provided (automation) changelog entry is part of PR label May 16, 2025
"""Dotted name and parts."""
if namespace_package:
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I kind of piggybacked on the existing test that covers this functionality, but not sure whether it's a bit dirty!
Please let me know if you'd prefer me to do it in some other way, e.g. create a new fixture specifically for this case. Or perhaps this should be tested in some different place rather than test_main?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @karlicoss,

I think it is perfectly fine to reuse an existing test like this one, thanks!

However functionality related to collection and packages tends to break complex test suites in subtle ways... been there done that.

But to be honest not sure how we can even foresee how this will be handled in the wild, unless we put it in the wild.

I'm considering adding this behind a feature flag, so if it causes havoc, we can optionally revert it...

On the other hand, we can just bite the bullet and see. If this causes massive breakage, we can always revert the patch and make a hot fix.

Just thinking aloud here.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On the other hand, we can just bite the bullet and see. If this causes massive breakage, we can always revert the patch and make a hot fix.

No, agree, it makes a lot of sense! From experience, such random breakages are pretty annoying. Happy to implement a feature flag and add documentation for it.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've been thinking about the flag name & documentation.. and actually, perhaps it makes sense to simply reuse consider_namespace_packages?


From my experience with it, right now only helps with package/module names. E.g. if there is a test inside test_pkg.py

src/
    pkg/
        test_pkg.py

And we run PYTHONPATH=src pytest --pyargs pkg.test_pkg

It correctly discovers tests in both cases, but.

  • with consider_namespace_packages, it has __package == "pkg" and __module__ == "pkg.test_pkg" (as one might expect)

  • without consider_namespace_packages, it has __package == "" and __module__ == "test_pkg"

    If we add pkg/__init__.py, this has correct __package__ and __module__ though.

This is consistent with --help:

Consider namespace packages when resolving module names during import


However, according to https://docs.pytest.org/en/stable/reference/reference.html#confval-consider_namespace_packages

Controls if pytest should attempt to identify namespace packages when collecting Python modules. Default is False.
Set to True if the package you are testing is part of a namespace package.

So the docs say it "should attempt to idenfity when collecting", but I'm not sure what this actually means here.

E.g. if you have the following hierarchy:

src/
    pkg/
        __init__.py
        subpkg/
            test_subpkg.py

pkg is a regular package with __init__.py, but pkg.subpkg is a namespace subpackage.
Then if you run PYTHONPATH=src pytest --pyargs pkg (with upstream pytest), pytest correctly discovers the test in test_subpkg.py

The only difference is

  • with consider_namespace_packages it correctly sets __package__ and __module__ in test_subpkg.py
  • without, it sets __package__ = ""

From a lurk in pytest code, to me it feels that indeed it has to do more with naming than test discovery -- e.g. I think stuff in this file is mostly after we already collected candidate files to run?

consider_namespace_packages: bool,


So perhaps if I just reuse consider_namespace_packages, this makes it closer to the original intent? So it could both discover tests under namespace packages (this PR), and they also will have correct __package__/__module__ attributes (already working in upstream pytest).

This also limits the potential impact from the change -- there are "only" 400ish matches for this setting on github https://github.com/search?q=consider_namespace_packages&type=code (tiny amount comparing to total pytest users), and I'd imagine people who use this setting know what they are doing anyway.

What do you think?

Copy link
Member

@nicoddemus nicoddemus left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks a lot for tackling such a long standing issue @karlicoss , appreciate it!

"""Dotted name and parts."""
if namespace_package:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @karlicoss,

I think it is perfectly fine to reuse an existing test like this one, thanks!

However functionality related to collection and packages tends to break complex test suites in subtle ways... been there done that.

But to be honest not sure how we can even foresee how this will be handled in the wild, unless we put it in the wild.

I'm considering adding this behind a feature flag, so if it causes havoc, we can optionally revert it...

On the other hand, we can just bite the bullet and see. If this causes massive breakage, we can always revert the patch and make a hot fix.

Just thinking aloud here.

@@ -0,0 +1 @@
Support PEP420 (implicit namespace packages) as `--pyargs` target.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we add a section to the docs related to this support somewhere in the docs?

# If submodule_search_locations is set, it's a package (regular or namespace).
# Typically there is a single entry, but documentation claims it can be empty too
# (e.g. if the package has no physical location).
return spec.submodule_search_locations[0]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps instead of just returning it blindly, we should check if this is a directory before returning?

karlicoss added a commit to karlicoss/pymplate that referenced this pull request May 26, 2025
looks lik all good, allows to get rid of horrible conftest hacks!
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bot:chronographer:provided (automation) changelog entry is part of PR
Projects
None yet
Development

Successfully merging this pull request may close these issues.

--pyargs does not understand namespace packages
2 participants